home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000373_marca@wintermu….ncsa.uiuc.edu _Sat Nov 21 04:04:57 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  2KB
  1. Return-Path: <marca@wintermute.ncsa.uiuc.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA05567; Sat, 21 Nov 92 04:04:57 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA22777; Sat, 21 Nov 92 04:17:42 +0100
  6. Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA28422
  7.   (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Fri, 20 Nov 92 21:17:25 -0600
  8. Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
  9.     for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA14876; Fri, 20 Nov 92 21:18:36 -0800
  10. Date: Fri, 20 Nov 92 21:18:36 -0800
  11. From: marca@ncsa.uiuc.edu (Marc Andreessen)
  12. Message-Id: <9211210518.AA14876@wintermute.ncsa.uiuc.edu>
  13. To: Dan Connolly <connolly@pixel.convex.com>
  14. Cc: marca@ncsa.uiuc.edu (Marc Andreessen), www-talk@nxoc01.cern.ch
  15. Subject: Re: Annotation & asynch collaboration 
  16. In-Reply-To: <9211210309.AA13411@pixel.convex.com>
  17. References: <9211210309.AA13411@pixel.convex.com>
  18.     <9211210500.AA14826@wintermute.ncsa.uiuc.edu>
  19.  
  20. Dan Connolly writes:
  21. > >ANNOTATE /file/to/annotate?/file/of/annotation?Text describing annotation.
  22. > 
  23. > I'd suggest
  24. > 
  25. > APPEND /file/to/annotate
  26. > <a HREF="file/of/annotation">Text describing annotation</a>
  27. > .
  28. > 
  29. > The server could impose limits on the length of the annotation,
  30. > and it should somehow validate the syntax, I suppose.
  31.  
  32. The point behind *not* doing general appends is that they aren't a
  33. good idea since document integrity is breached (a link is immediately
  34. obvious as just that and will cause little confusion [especially if
  35. clients always prepend a fullname], but if arbitrary text can be added
  36. to a document, you'll never know what's going on).  To be practical, I
  37. know *I'm* not going to run an httpd server that allows anyone to
  38. append any text they want to my documents.
  39.  
  40. And if general appends aren't going to be allowed (through server
  41. validation of the <A...> syntax or whatever), then why not just let
  42. the server construct the link append itself?
  43.  
  44. Marc
  45.